\documentclass[a4paper]{article}

\usepackage[dutch]{babel}
\usepackage{multicol}
\usepackage{a4wide}
\usepackage{color}
\usepackage{graphicx}

\setcounter{tocdepth}{2}

\title{Series 3: ASF+SDF}

\author{Nico Schoenmaker en Menno Middel}

\usepackage[pdfhighlight=/N,colorlinks=true]{hyperref}

\newcommand{\fixme}[1]{\textcolor{red}{\textbf{[fixme!]#1[fixme!]}}}

\begin{document}

\maketitle

%\tableofcontents

%\begin{abstract}
%
%\end{abstract}

\section{Opdracht 0: Conceptuele overview}

	Voor informatie over de broncode hebben wij twee feiten
	geidentificeerd. Het gaat om de aantal lines of code en de McCabe
	complexity. Bij de Lines of code worden de feiten gegroepeerd per
	classe. Bij de McCabe complexity worden de feiten gegroepeerd per
	methode. In afbeelding \ref{fig:loc} (Lines of Code) en
	\ref{fig:mccabeComplexity} (McCabe Complexity) zijn dataflow
	diagrammen van beide situaties weergegeven.

\begin{figure}[h!]
	\centering
	\includegraphics[width=0.5\textwidth]{loc}
	\caption{LOC dataflow diagram}
	\label{fig:loc}
\end{figure}

\begin{figure}[h!]
	\centering
	\includegraphics[width=0.5\textwidth]{mccabeComplexity}
	\caption{McCabe complexity dataflow diagram}
	\label{fig:mccabeComplexity}
\end{figure}

	In de diagrammen representeren de nodes een opslag. De pijlen geven de
	opdrachten die over de stores worden uitgevoerd aan waarbij de
	opslag aan de inkomende kant de invoer van een opdracht en de opslag
	aan de uitgaande kant de uitvoer van de opdracht zijn. De labels aan
	de rechter kant van de pijl geeft de naam van de opdracht.

	Het resultaat wordt opgeslagen in een tabel. Voor de lines of
	code wordt in deze tabel tuples opgeslagen met de naam van de classe
	en de aantal regels code die de classe bevat. Voor de McCabe
	complexity wordt in de tabel tuples opgeslagen met de naam van de
	methode en de McCabe complexity van deze methode. De tussengelegen
	resultaten zijn in de vorm van een parse tree. Een 'bad' statement
	is in deze een statement welke complexiteit toevoegd aan de methode.

\section{Opdracht 2: Java source-to-source transformation}

	\subsection{Opdracht 2.2}

		Op basis van de naam van de directory kregen wij het vermoeden
		dat het om java 5.0 (vroeger 1.5). Dit vermoeden hebben wij
		bevestigd door de foreach loop syntax definitie op te zoeken
		met:

		\begin{verbatim}
			find ./ | grep -v .svn | xargs grep -i foreach
		\end{verbatim}

		Het resultaat gaf een regel uit
		languages/java-15/expressions/MethodInvocation.sdf die de syntax
		definitie van de foreach loop gaf. De foreach loop is een nieuwe
		feature sinds java 5.0. Dit betekend dat dit de definitie is van
		java 5.0 of hoger, waarbij wij aannemen dat het java 5.0
		betreft.

	\subsection{Opdracht 2.4}

		De transformatie tool die wij ge\"{i}mplementeerd hebben maakt een
		getter en setter aan voor alle public field waarbij hij niet
		kijkt of de field al een getter en setter heeft. Verder heeft de
		ontwikkelaar misschien een goede reden om de fields public te
		houden, om bijvoorbeeld een API backwards compatible te houden.
		Door een field private te maken in API classes veranderd de API
		en wordt deze inconsistent met de oude API.

		Een aangelegen punt is dat, in onze huidige implementatie,
		aanroepen naar de voormalig publieke variabelen nog niet worden
		vervangen door een aanroep naar de betreffende getter of setter.
		
		Verder past de stijl van de gegenereerde code slecht in de
		huidige code. In onze huidige implementatie wordt de getter en
		setter direct onder het getransformeerde field gezet waarbij
		geen inspringing gebruikt wordt. Dit vervuild de code in het
		geval dat de ontwikkelaar een vast patroon gebruikt voor het
		indelen van de classe definitie die van die wij gebruikt hebben
		afwijkt. Het probleem in het vinden van een oplossing is vooral
		dat deze keuze voor het indelen van de classe definitie en het
		formatten van de code verschilt per ontwikkelaar of project. De
		transformatie zal de leesbaarheid van de code hierdoor kunnen
		aantasten.

		Om deze problemen op te lossen kunnen we de gegeven java
		definitie aanvullen met een definitie voor getters en
		setters. We kunnen dan een transformatie uitvoeren waarbij
		eerst alle bestaande getter en setter methoden in een lijst
		worden opgeslagen. Bij het transformeren van de public variablen
		kan er dan gecontroleerd worden of de getter of setter al
		bestaat. Wanneer dit niet het geval is kan een nieuwe getter en
		setter worden toegevoegd aan de lijst. Aan het einde kunnen de
		getters en setters bij elkaar in het resultaat op dezelfde plek
		in de classe definitie worden neergezet. Hierbij zal de
		codestyle nog steeds moeten worden aangepast om op het huidige
		project aan te sluiten.

		Door te identificeren welke classen tot de API behoren en deze
		uit te sluiten bij de transformatie kunnen we het probleem van
		de inconsistente API's voorkomen. Dit vereist helaas wel een
		extra handmatige controle voordat de transformatie uitgevoerd
		kan worden.

\section{Opdracht 3: Java fact extraction and analysis}

	\subsection{Opdracht 3.0: Unix commands}

		\paragraph{What is the total number of lines of code?}

		\begin{verbatim}
		find ./ | grep -v \.svn | grep \.java$ | xargs cat | wc -l
		\end{verbatim}

		We hebben ervoor gekozen om alle regels code te tellen. Dit omdat
		het lastig is om multi-line comments ( /* .... */ ) te tellen met de
		unix commandos. Het is mogelijk om alle regels niet mee te nemen welke
		beginnen met /*, * of //. Door dit te doen gaat de kwaliteit van het resultaat
		echter achteruit, omdat hierdoor bijvoorbeeld in het volgende voorbeeld de
		tweede regel niet als commentaar zou worden gezien.
		\begin{verbatim}
		/* Eerste comment
		   Tweede comment
		*/
		\end{verbatim}
		Deze stijl wordt bijvoorbeeld in de licentie bovenin ieder bestand gebruikt en
		zou de resultaten be\"{i}nvloeden.\\
		\\
		De andere overweging is of lege regels wel of niet meegeteld
		moeten worden.  We hebben ervoor gekozen om deze regels wel mee
		te tellen, omdat we aannemen dat programmeurs meer lege regels
		zetten bij complexe code. Deze aanname baseren we op observaties
		uit de praktijk.Om lege regels niet mee te tellen zou het
		volgende commando kunnen worden gebruikt: 
		\begin{verbatim} 
		find ./ | grep -v \.svn | grep \.java$ | xargs grep -v "^\s*$" | wc -l 
		\end{verbatim}

		\paragraph{What is the total McCabe complexity of the system?}
		\begin{verbatim}
		find ./ | grep -v \.svn | grep \.java$ | xargs cat | grep -e "^\s*if" -e "^\s*else"
		-e "^\s*while" -e "^\s*switch" -e "^\s*case" -e "^\s*for" | wc -l
		\end{verbatim}
		Geeft in totaal 3954 keer een regel welke begint met if, else,
		while, switch, case of for. De and en or constructies die
		origineel wel worden meegenomen in de berekening van de
		McCabe complexity, hebben wij hierbij genergeerd. Het
		menenemen van deze zaken voegt complexiteit toe aan onze
		oplossing. In de opdracht wordt expliciet om een simpele
		oplossing gevraagd.\\
		\\
		De regel is eenvoudig aan te passen om het antwoord per class te
		geven:
		\begin{verbatim}
		find ./ | grep -v \.svn | grep \.java$ | xargs grep -c -e "^\s*if" -e "^\s*else"
		-e "^\s*while" -e "^\s*switch" -e "^\s*case" -e "^\s*for
		\end{verbatim}
		Gesorteerd per class:
		\begin{verbatim}
		find ./ | grep -v \.svn | grep \.java$ | xargs grep -c -e "^\s*if" -e "^\s*else"
		-e "^\s*while" -e "^\s*switch" -e "^\s*case" -e "^\s*for" | sort -t ':' -k 2,2 -n
		\end{verbatim}
		Aangenomen dat de resultaten hiervan correct zijn, blijkt
		hieruit dat de JSPWikiMarkupParser class de hoogste
		complexiteit heeft, met een McCabe complexity van 310.

	\subsection{Opdracht 3.1: One example of an analysis that would be hard to implement}

		Een analyse wordt lastig te implementeren wanneer er sprake is
		van nesting, zoals bijvoorbeeld het tellen van het diepste
		nesting niveau in een class. Het tellen van het aantal if's is
		haalbaar, maar wanneer het diepste nesting niveau moet worden
		achterhaald is het onmogelijk dit te achterhalen met een tool
		als grep. Er moet dan eerst een parse tree worden gemaakt.

	\subsection{Opdracht 3.3: Precision of 3.0 and 3.1.}
	
		In assignment 3.0 zijn we uitgegaan dat alle keywords op het
		begin van de regel staan. Vaak is het zo dat een keyword op het
		begin van een regel staat. Deze kennis hebben we gebruikt om te
		voorkomen dat keywords, welke in comments staan, worden
		meegeteld. Dit heeft als gevolg dat een keyword, welke niet aan
		het begin van een regel staat, niet wordt meegeteld in de
		analyse.

		Daarnaast kan er gebruik gemaakt zijn van een ternary statement,
		zoals bijvoorbeeld:
		\begin{verbatim}
		variabele = voorwaarde ? a : b;
		\end{verbatim}
		Ondanks dat ternary operations wel bijdragen aan de
		complexiteit, worden deze niet meegeteld in onze analyse
		in 3.0 om de cyclomatic complexity te berekenen.

		Tenslotte kan het zo zijn dat de naam van een variabele
		begint met een keyword. Iedere keer dat deze variabele aan het
		begin van een regel staat zal deze ook worden meegeteld.
		\begin{verbatim}
		switchedPage = page;
		\end{verbatim}

%\bibliography{bibliography}

%\bibliographystyle{plain}

\end{document}

% vim: textwidth=72:shiftwidth=4:tabstop=4:smartindent
